home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9704 / 000030_owner-urn-ietf _Wed Apr 23 15:14:36 1997.msg < prev    next >
Internet Message Format  |  1997-04-30  |  12KB

  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id PAA15897
  3.     for urn-ietf-out; Wed, 23 Apr 1997 15:14:36 -0400 (EDT)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id PAA15890
  6.     for <urn-ietf@services.bunyip.com>; Wed, 23 Apr 1997 15:14:31 -0400 (EDT)
  7. Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA14353  (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Apr 97 15:14:26 -0400
  9. Received: from localhost (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) with SMTP id PAA25039; Wed, 23 Apr 1997 15:14:25 -0400
  10. X-Authentication-Warning: beethoven.bunyip.com: leslie owned process doing -bs
  11. Date: Wed, 23 Apr 1997 15:14:24 -0400 (EDT)
  12. From: Leslie Daigle <leslie@Bunyip.Com>
  13. To: minutes@ietf.org
  14. Cc: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, urn-ietf@bunyip.com
  15. Subject: [URN] URN WG Minutes
  16. Message-Id: <Pine.SUN.3.95.970423151239.24942F-100000@beethoven.bunyip.com>
  17. Mime-Version: 1.0
  18. Content-Type: TEXT/PLAIN; charset=US-ASCII
  19. Sender: owner-urn-ietf@Bunyip.Com
  20. Precedence: bulk
  21. Reply-To: Leslie Daigle <leslie@Bunyip.Com>
  22. Errors-To: owner-urn-ietf@Bunyip.Com
  23.  
  24. Here are the minutes from the URN Working Group meeting in Memphis, April 10, 
  25. 1997.
  26.  
  27.           Minutes of the URN Working Group
  28.             38th IETF Memphis TN
  29.             April 10, 1997
  30.  
  31. Session Chair - Leslie Daigle, Bunyip
  32. Minutes: Sally Hambridge - Intel
  33.  
  34.  
  35. Summary:
  36.  
  37.  
  38. The URN Working Group met and discuessed the status of submitted RFCs 
  39. and drafts.  There are 3 documents which have gone to the IESG: The
  40. URN Syntax draft as proposed standard, The NAPTR document, which has
  41. gone as experimental, and the THTTP draft, also experimental.  There
  42. are also 3 new drafts and one revised draft, although one "draft"
  43. did not make it to the ID editor by the deadline for the Memphis meeting.
  44. After discussing all the documents, the group reviewed progress to date
  45. on milestones and agreed to a revised set of dates for deliverables.
  46. Finally, they agreed to creating a FAQ to document decisions, and
  47. to using the RFCs as a new namespace (pending IESG approval).
  48.  
  49.  
  50. Minutes:
  51.  
  52. Leslie opened the meeting by reviewing the status of the charter.  We
  53. have not met all the milestones although we have made substantial progress.
  54. The group has 3 documents which have gone to the IESG:  The URN Syntax
  55. has gone as a proposed standard, the NAPTR document has gone as an 
  56. experimental document, and the THTTP document has also gone as an
  57. experimental document.  The group has 3 new drafts and one revised draft.
  58. There are relatively few things left as milestones which we have to
  59. produce so it is conceivable that Munich might be our last meeting.
  60.  
  61. Karen Sollins presented the Framework and Requirements Document and
  62. began by talking about the Security requirements.  She has added some
  63. paragraphs on potential threats and how to deal with them in the
  64. framework (not mechanisms to deal with them).  She noted that there
  65. was clarification needed about the words "authoritative" which could
  66. mean it must be possible to have a version by a person authorized to 
  67. write it, or there must be a certified version.  Both should be 
  68. possible.  She also noted that "access control" could mean access for
  69. read only, for read and modify, and for read with verification.  There
  70. also needs to be a means for certification without passing the original
  71. record.
  72.  
  73. Leslie then wondered if the draft should really be called a "Requirements"
  74. document when we would not be able to see far enough into the future to
  75. be able to state categorically what needed to be a requirement.  John
  76. Curran thought the draft was much better than previous versions as one
  77. could easily relate paragraphs to requirements, but he too felt uneasy
  78. with the word "requirements".  After much discussion, we agreed (ROUGH
  79. CONSENSUS - FAQ maintainer take note) that the Document should proceed
  80. but needed to be called Guidelines or Considerations for an RDS rather
  81. than Requirements.  Karen felt that ubiquity and scalibility were
  82. requirements (or considerations) which were still missing from the 
  83. document, and urged us to take up discussion of these issues on the
  84. list.
  85.  
  86. John Curran said that in the future, after we have operational experience
  87. we (not in the lifespan of this working group) needed to produce a crisp 
  88. requirements document and that Karen's doc would continue to proceed as 
  89. informational.
  90.  
  91. Michael Mealling spoke to the URN Resolution Services draft.  He
  92. said he had drawn most of the content from the THTTP draft.  He felt
  93. that the scope of the document was larger than the working group 
  94. charter, since it encompassed other URI services.  Karen suggested
  95. he needed to be clearer that he was not talking about a global RDS
  96. but about local resolution services.  The draft also needs a section
  97. on security considerations, and on error processing.  John C. pointed
  98. out that Text/URI was not registered as yet, and Ron Daniel admited 
  99. he needed to do that.  Karen S said she was not happy with the example
  100. and that we needed to be clearer about "today's weather" and " a weather
  101. map for April 10, 1997" which were 2 separate things which might have
  102. a point in time of overlap and Michael agreed that a concept of equality
  103. which is time-based needs to be clarified.
  104.  
  105. Finally, we agreed (ROUGH CONSENSUS) that the draft needed to be called 
  106. URI Services necessary for URN Resolution services and that it could
  107. proceed as either informational or experimental.  Again, a standards-track
  108. document will be revisited after operational experience has been gained.
  109.  
  110. Cliff Lynch presented the ID which is not quite an ID.  It had been
  111. posted to the list, but in a format that was not friendly for all
  112. mailers and needed to be re-posted.  Since the URN syntax has been 
  113. established, this draft explored how ISBNs and ISSNs as well as 
  114. Serial Item and Contribution Identifier Strings might map to URN.  There 
  115. are no particular syntax problems although some %HH encoding is required.
  116. This document is useful for showing how resolution will work in practice.
  117. ISSNs will probably take the user to a navigation apparatus because
  118. they represent an ongoing publication,  The apparatus will lead the
  119. user to a way to search/browse the serial desired.  The group made clear
  120. that this document showed how the bibliographic area mapped into the
  121. URN name space.  Ron pointed out a caveat that we hadn't talked about
  122. which standards bodies have control over the ISBN and ISSN space and
  123. Cliff assured him there was weasel language in the draft over this issue.
  124.  
  125. Patrik Faltstrom presented the Namespace Requirements draft.  This draft is 
  126. problematic because in trying to define the requirements for registering
  127. of a name space one fell into operational requirements for the registration
  128. process.  There has been some violent disagreement about what
  129. should be in the document, and Patrik and his co-author Renato (not able
  130. to be present at the meeting), did not even seem to be in agreement.  Patrik 
  131. thought it should deal with grandfathering in existing name spaces.  Renato 
  132. thought it should be about the registration process.  John C. suggested we 
  133. decide who the consumer of the document should be.  He suggested we presume 
  134. it was IANA, and that we should think about what IANA would need from the 
  135. document.  We decided (ROUGH CONSENSUS) that the document needed to go 
  136. forward as a non-judgemental checklist.  This lead to a discussion about
  137. the problems of having a checklist which avoided operations issues,
  138. and the problems of assigning names.  Michael Mealling mentioned that
  139. he needed some arbiter for this problem, and Leslie suggested he refer
  140. current name registration problems to the URN WG.  Leslie acknowledged that we 
  141. have problems with assigning name spaces: Is it a name space, Should 
  142. someone have the name?  What happens when "you" say "no"?  We are just
  143. NOT ready to address the "Can you have it" problem, and will focus
  144. for now on the technical issues of evaluation whether something COULD be a 
  145. namespace.
  146.  
  147. We spoke for quite a while on the problems of registering name spaces
  148. and discovered areas where there be dragons.  There seems to be large
  149. dragons where ownership is unclear.
  150.  
  151. To Summarize for existing drafts:
  152.  
  153. Requirements and Framework - will go through another round of editing, and
  154. continue on its way as informational with a change in focus from 
  155. "requirements" to "Considerations and Guidelines".
  156.  
  157. URN Resolution Services: Will go forward as FYI as the "List of URI
  158. Services needed by URNS"
  159.  
  160. Bibliographic IDs - is OK as a proof of the concept.  Will go quickly
  161. to last call  as informational after reposting to the list in a 
  162. format readable by all.
  163.  
  164. Namespace Requirements - Will describe technical considerations of 
  165. a namespace - not "Can you have it" issues.
  166.  
  167. We decided we needed a glossary which would define terms which spanned
  168. all the documents.  Dirk-Willem Van Gulik volunteered to be the
  169. glossary editor, and thought he could have a version which would be
  170. put on the web-page by July 1997.
  171.  
  172. Other Issues
  173.  
  174. Ryan Moats presented an Experimental URN namespace, in which he 
  175. took RFC's as the data.  The experiment is intended to help gain
  176. experience and insight into the namespace registration process and
  177. issues.
  178.  
  179. NID: "ietf"
  180. BNF grammar for NSS:
  181.  - <nss> := <family> ":" <number>
  182.  - <family> := "rfc" | "std" | "fyi"
  183.  - <number> := sequence number
  184.  
  185. Resolution functionality is currently: N2L, N2Ls, N2R, N2Rs, N2C
  186.  
  187. Introductory URL Page: http://dsm0.ds.internic.net/urn
  188.  
  189. URL for testing:
  190. http://dsm0.ds.internic.net:8080/urn-res/<function>>?<urn>
  191.  
  192. Michael said he will try NAPTR today as well.
  193.  
  194. Following on to Dan Connolly's suggestion on the mailing list, the group then 
  195. decided that decisions of the group needed to be captured somehow, so we did 
  196. not have to contantly revisit decisions.  We decided (ROUCH CONSENSUS) to 
  197. create a FAQ which could be posted to the list periodically.  Leslie will 
  198. write the first iteration of the FAQ.  One of the first things to be 
  199. documented will be the decision surrounding the use of urn:
  200.  
  201. There is a new URL syntax draft (draft-*-fielding---.04.txt) which has
  202. ONE paragraph which says that URL syntax is for all URIs.  We will
  203. approach the editors and ask them to change it.  We need to demonstrate
  204. the lack of consensus from the URN working group that the URL
  205. syntax draft applied to URNs.  There is very good work in the draft 
  206. about relative URLs.  
  207.  
  208. We then reviewed the milestones and decided that the only work which was
  209. absent was work on a new namespace.  We elected to use Ryan Moats 
  210. experiment with the RFCs pending approval from the IESG.  The new 
  211. milestones are:
  212.  
  213. May 97
  214.      Submit revised grandfather namespace document as Internet-Draft.
  215. May 97
  216.      Submit revised N2L/N2R/etc document as an Internet-Draft.
  217. May 97
  218.      Submit revised namespace requirements document as an Internet-Draft.
  219. May 97
  220.      Submit document describing one (new) namespace as an Internet-Draft.
  221. May 97
  222.      Submit Framework (Guidelines) document to IESG for publication as an RFC. 
  223. Jul 97
  224.      Submit N2L/N2R/etc document to IESG for publication as RFC.
  225. Jul 97
  226.      Submit grandfathered namespace paper to IESG for publication as RFC.
  227. Jul 97
  228.      Submit revised new Namespace document as Internet-Draft.
  229. Aug 97
  230.      Submit new namespace proposal to IESG for publication as RFC
  231.  
  232. The meeting ended on time.
  233.  
  234.  
  235.  
  236.  
  237.  
  238. ----------------------------------------------------------------------------
  239.  
  240.   "_Be_                                           Leslie Daigle
  241.              where  you                           
  242.                           _are_."                 Bunyip Information Systems
  243.                                                   (514) 875-8611
  244.                       -- ThinkingCat              leslie@bunyip.com
  245. ----------------------------------------------------------------------------
  246.